Synchronization refers to the requirement that the transmit and receive ends of a digital communication networks operate at the same clock rate. A network clock located at the transmitter node controls the rate at which data is transmitted. A second network clock located at receiver controls the rate at which data is read. For the receiver to properly interpret incoming data, its clock needs to be synchronized to the transmitter clock. There are different ways for synchronizing clock over networks. In some network configurations (e.g. TDM networks), transmitter clock information can be extracted directly from data and used in the receiver to synchronize the two clocks. Due to low cost and availability of packet networks, many service providers are looking into transporting legacy services (such as TDM services) over IP based networks. The main problem is how to maintain the same level of synchronization as in legacy network. Although there are different approaches for solving this problem, the one approach that has potentially many advantages over the others (including cost and availability) is clock synchronization using dedicated timing packets.
FIG. 1 is an illustration of this approach. At the transmitter side dedicated timing packets are time-stamped by the transmitter's clock and then sent over the packet switched network (PSN) to one or multiple receivers. At the receiver side these timing packets are time-stamped by the receiver clock as they arrive. The difference between these two time stamps represents the relative delay between the transmitter and receiver's clocks. This can be used to synchronize the two clocks. One advantage of this approach is that it does not require extra means or modifications to the physical layer for synchronizing the clocks, and it is widely available (as long as there is IP network). Nonetheless this approach has its own challenges.
One of the main challenges with this approach is that timing packets are subject to packet delay variations (PDV) inherent to any packet switched networks. As a result at the receiver side, depending on packet delay variations, the recovered reference clock will have a high level of jitter and wander, which will not be acceptable for many applications, especially legacy services that assume high quality level of synchronization.
To overcome this issue, it has been proposed to filtering the timing packets at the receiver such that only those timing packets that are least subjected to packet delay variations are used for clock recovery.
U.S. Pat. No. 6,658,025 describes a method for filtering timing packets where the expected arrival time for each timing packet is estimated and compared to the actual arrival time. Then a number of timing packets with the most deviation from expected value are discarded and the remaining timing packets are used to recalculate a new expected value for arrival time. The new calculated expected value again is used to discard a new series of timing packets and this process continues until certain number of timing packets has been discarded. Whatever timing packets remain after this elimination process are then used to correct any frequency offset between the transmitter and receiver clocks.
Likewise, U.S. Pat. No. 7,315,546 employs a method that, instead of discarding timing packets, uses a weighted set of timing packets to synchronize the receiver and transmitter clocks. Weightings are calculated based on the distance between the expected arrival time and the actual arrival time of the timing packets. In this fashion, the timing packets with the largest distance from the expected delay are given the least amount of weighting.
In both methods timing packets are filtered based on their closeness to some initial estimate of delay between transmitter and receiver. Because of this, the performance of both the above methods depends highly on the accuracy of the calculated expected delay. If due to so-called “outliers”, namely packets with large deviations in delay from the norm, the initial estimate is not correct then all subsequent filtering process will be wrong and method will be unable to achieve a lock. Also both methods use blocks of input timing packets to update the expected delay. This will limit the tracking behaviour in the case where there is rapid change of delay between the transmitter and receiver e.g. due to a reroute in the packet network.